#670: #592-B: GTK live path — paint the panel surfaces (quickfix, bottom_tabs, debug_toolbar, panel_hover, ai_panel) - #685

…K's live render_content path

Sub-task 2/4 of #592 (part B of the panel-surfaces group). These four
screen.* fields were populated by the engine the whole time but never
painted on GTK's live path since the #540 Relm4->ShellApp migration
replaced the now-dead src/gtk/draw.rs — same root cause #669 fixed for
the editor overlay popups.

- render.rs: two new shared adapters for panel_hover — panel_hover_anchor_y
  (lifted from draw.rs's source-control section walk, generalized to take
  an explicit sidebar_top_y instead of assuming the sidebar starts at
  pixel 0) and panel_hover_popup_paint (mirrors editor_hover_popup_paint's
  unit_w/unit_h convention, routing through the same RichTextPopup /
  Backend::draw_rich_text_popup path TUI's render_panel_hover_popup
  already uses). Quickfix, the bottom panel (terminal/debug output) and
  the debug toolbar needed no new adapters — quickfix_to_list_view,
  build_bottom_panel_tab_bar, build_terminal_toolbar,
  build_terminal_draw_data, debug_output_to_text_display and
  draw_debug_toolbar were already shared with TUI; only the paint call
  was missing on GTK.
- gtk/mod.rs: render_content now paints all four surfaces in GTK pixel
  units. Along the way, fixed a layout bug the new paint calls exposed:
  editor_area_h never reserved quickfix's band (so editor content painted
  straight through it) and status_y subtracted terminal_h/debug_toolbar_h/
  separated_status_h from itself, which put the global status bar *above*
  the terminal panel instead of below it whenever one was open. Both now
  derive from compute_editor_layout's el.editor_bottom (already correct,
  already shared with TUI) instead of a second, incomplete local copy.
  debug_toolbar_y_offset/height (existing but never-written cache fields)
  are now populated too.
- gtk/testing.rs: four GtkDriver black-box tests. Quickfix/terminal/
  debug-toolbar compare two *open* states that differ only in content
  (selection index, active tab, session state) rather than open-vs-closed
  — opening any of these panels alone reserves its band and swaps painted
  editor text for panel background, which would make an open-vs-closed
  pixel comparison pass even with the actual paint call deleted. Verified
  each of the four goes red by temporarily deleting its paint call and
  confirming the assertion panics, then restored it.

ai_panel (the fifth surface #670 scoped) needs a genuinely new render.rs
adapter — GTK's dead draw_ai_sidebar was hand-rolled raw Cairo/Pango, not
routed through any existing Backend primitive, unlike these four — so
it's split into a follow-up issue per #670's own escape hatch rather than
letting it swallow this session.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>